home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Tools & Utilities
/
Collection of Tools and Utilities.iso
/
dskut
/
tstdisk.zip
/
TESTDISK.DOC
< prev
next >
Wrap
Text File
|
1989-12-28
|
13KB
|
224 lines
TESTDISK
THE NEXT GENERATION OF DISK THROUGHPUT BENCHMARKS
(c) COPYRIGHT 1988-1989 BY
COLUMBIA DATA PRODUCTS, INC.
1070B RAINER DRIVE
P.O. BOX 2584
ALTAMONTE SPRINGS, FL 32714-2584
(407) 869-6700
Welcome to the world of hard disk performance measurement! Until
recently, measuring performance of disk subsystems for the IBM
PC/XT/AT/PS2 and compatibles has been somewhat over simplified by
the industry. Now, with the introduction of SST-equipped
controllers, contemporary benchmarks are no longer adequate to
predict disk subsystem performance in actual everyday use.
Benchmarks for the next generation of mass storage systems for
the IBM PC/XT/AT/PS2 and compatibles now require that more
variables be taken into account to accurately measure the
throughput a system can achieve.
ACCESS TIMES
Until now the only major variable that generally was considered
was the Average Disk Head Seek Time, expressed in milliseconds
(commonly referred to as Average Access Time). From the
standpoint of a disk drive manufacturer, this is the major item
which is used to market their products and they are consistently
touting faster and faster access times. But the REALLY important
aspects of overall disk system performance are just not shown.
Let's take a disk that has an access time of 20 milliseconds, for
example. Does that mean that just because it has a 20
millisecond access time that it is fast? Well, yes and no. It
means that it can move the disk head from one spot on the disk to
another spot on the disk in an overall average of 20
milliseconds. As far as access times go, a 20 millisecond
average access time disk drive is relatively fast. But it tells
you nothing of how fast it will deliver data to your computer.
So you ask, "Well, then, how can I tell when a disk drive is
fast?" Read on!!
Disk performance really starts at your hard disk controller--not
at your disk. Disk performance is a function of how rapidly data
can be transferred from the hard disk into your computer. If you
have a disk controller which can move data at 29,000 characters
per second (which is not uncommon), then it stands to reason that
it will take you six seconds to load your 174,000 character
spreadsheet. So, whether you have a 20 millisecond hard disk or a
65 millisecond hard disk, it still takes six seconds to recover
your spreadsheet!!
DATA RATES
As you can probably tell, disk performance measurement, which
tells you how long you are going to wait for something to load
into your computer from your hard disk, can best be expressed in
characters per second. Since one character is equal to one byte,
and most disk systems move data in thousands of bytes (or
characters) per second, the standard term for data rate is
kilobytes (1024 bytes) per second (KBS).
Some benchmark tests actually DO report the data transfer rate
(in KBS) of the controller. They measure the movement of data
from the disk to memory. They only report, however, the highest
data rate your disk drive can achieve on your computer. Now, if
you read closely, you will notice that I said the HIGHEST data
rate your disk drive can achieve on your computer. Does this
mean that there is more than one data rate expressed in KBS which
can be achieved by your disk system? The answer is YES!
WHICH DATA RATES?
Whenever the disk system is asked to move data from the hard
drive into memory or vice versa, it takes time for the disk
system to figure out what you are asking for, where it is on the
disk, and how to move the data. This time lag is called command
processing latency. It is this initial time lag before data is
actually moved to or from the disk that is the evil of disk
performance. Since this time lag is pretty much a constant, it
is wise to get as much data off of the disk at one time rather
then to repeatedly ask for data in small blocks. For example, if
you wanted to move 327,680 bytes off the disk and the initial
command processing latency was 70 milliseconds (70/1000 of a
second) and the 327,680 bytes was moved in 512 byte blocks, you
would be asking the disk to move data 640 times and your command
processing latency alone would be 44.8 seconds (640 X .070
seconds)!!
If, however, you moved the 327,680 bytes off the disk 65,536
bytes (64 KB) at a time, you would be asking the disk to move
data only 5 times and your command processing latency would be
35/100's of a second (5 X .070 seconds). That is 992% faster!!!
44.8 seconds compared to a fraction of a second and that's not
even counting the time to move the data!! This is extremely eye
opening isn't it?
So, you see, it doesn't appear to be very wise to ask the disk
for data in small blocks, now does it? But this is precisely the
way most application programs (such as Lotus, Dbase, etc) DO move
their data--512 bytes at a time. Now, these other disk
performance testers I mentioned, test the disk by moving data
65,536 bytes at a time. So, you have absolutely no idea how fast
Lotus, Dbase, or any of the other application programs can
retrieve data. All you know, is that IF YOUR PROGRAM MOVED DATA
64K AT A TIME OFF THE DISK, THIS IS HOW FAST IT WOULD BE!! In
essence, then, to measure disk performance in 64K blocks is
utterly useless to you if you really want to know how fast your
application program can load data.
Your Columbia Data Products disk performance tester, TESTDISK,
doesn't just move data off the disk in 64K blocks. It moves the
data in 8 different size blocks: 1/2K, 1K, 2K, 4K, 8k, 16K, 32K
and 64K. This will give you a clear idea of how fast your disk
system really is. When you run this on a disk system which is
650 KBS at 64K blocks, you may be surprised to find that it is
only 120 KBS (or less) at the 1/2K block rate. You may even find
that you paid a premium for a "fast" disk system and you never
will see the "speed" because the programs you run cannot utilize
it.
One last word about average access times. They are important.
We at Columbia Data Products do not dispute that. They account
for a sizeable portion of your command processing latency. You
should not, however, pay a premium for a "fast" access time if
you can't take advantage of it. This test will help you
determine that. The last example I wish to give will compare two
hard drives. The first hard drive has a 1 millisecond average
access time and the other has a 100 millisecond average access
time. The 1 millisecond access time hard drive can move data off
itself and into the computer at 100 thousand bytes per second
(100 KBS). The 100 millisecond access time hard drive can move
data off itself and into the computer at 900 thousand bytes per
second (900 K